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PREFACE 


77ie  Finance  Near-Term  Technical  Architecture  will  provide  the  integrated  guidance, 
design  concepts,  and  migration  strategies  that  govern  the  consoiidation  and  evolution 
i'  r, ;  finance  and  accounting  technical  infrastructure. 


Tnis  release  of  the  Architecture ,  Version  1. 1,  is  based  on  the  previous  versions  and 
incorporates  the  majority  of  the  user  supplied  comments.  This  version  includes 
updates  to  the  following  sections :  Transaction  Processing,  Video  Teleconferencing, 
Electronic  Data  Interchange,  Operating  Systems,  Application  Programming 
Languages,  Database  Management,  Data  Interchange,  and  Workstations.  Several 
sections  of  the  architecture  not  included  in  this  current  version  will  be  included  in 
future  versions  of  the  architecture  as  they  are  completed.  \ 

The  next  version  of  the  Architecture  will  include  updates  to  Imaging,  Security,  and 
Communications.  \ 


The  architectu  %vili  evolve  based  on  comments  and  feedback  form  the  finance 
technical  and  :unctional  integrators,  the  Defense  lnformation\Technology  Services 
Organization  (DITSO),  and  the  finance  community  in  general}  Please  address  all 
comments  to: 


Mr.  John  Peiszynski 
CIIWOTI 

5201  Leesburg  Pike 
Suite  1501 

Falls  Church,  VA  22041-3201 


Phone:  (703)  756-7800 
FAX  :  (703)  756-7752 
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1.0  INTRODUCTION 


This  document  describes  the  support  applications,  computing  platforms, 
and  communications  networks  needc-^  to  provide  the  technical 
infrastructure  for  the  finance  community.  It  will  be  used  to  guide  the 
evolution  of  the  finance  technical  infrastructure  in  support  of  their 
specific  requirements.  System  alternatives,  economic  analysis,  detailed 
migration  options,  and  implementation  guidance  will  be  provided  in 
separate  documents. 

1.1  Background 

The  current  Department  of  Defense  (DoD)  finance  and  accounting  technical 
infrastructure  consists  largely  of  stovepipe,  single  purpose,  and  inflexible 
systems  which  are  costly  to  develop  and  maintain.  There  exists  over  450 
limited  purpose  systems  using  a  wide  variety  of  computing  and 
communications  technology.  The  use  of  this  large  number  of  systems 
often  contributes  to  redundant  inefficient  management  of  DoD  resources. 

The  existing  technical  infrastructure  fails  to  provide  the  centralized 
management,  flexibility,  and  interoperability  required  to  support  new 
business  practices,  consolidation  efforts,  and  rapid  user  access  to 
required  information.  More  importantly,  it  fails  to  integrate  the  multi- 
IPC/CDA  infrastructure  which  was  capitalized  into  DFAS  and  does  not 
satisfy  regulatory  requirements  for  interoperability. 

1.2  Purpose 

The  Technical  Architecture  provides  the  integrated  guidance  that  governs 
the  evolution  of  the  finance  and  accounting  technical  infrastructure,  it 
provides  the  services,  standards,  design  concepts,  and  migration 
strategies  that  will  be  used  to  develop  a  technical  infrastructure  that 
conforms  to  DoD  standards  and  guidelines.  The  Technical  Architecture 
forms  the  foundation  for  introducing  and  promoting  interoperability, 
portability,  and  scalability  of  finance  and  accounting  systems. 


Although  the  eventual  goal  is  a  common,  cross-functional,  standards- 
based  technical  infrastructure,  the  architecture  does  not  drive  the  finance 
technical  environment  directly  to  open  systems  compliance.  Instead  it 
focuses  on  a  phased  migration  approach  which  initially  creates  the  best 
possible  technical  infrastructure  from  existing  technology  components 
within  the  finance  and  accounting  inventory.  Opportunities  to  position  for 
future  migration  to  open  systems  compliance  are  exploited  wherever 
possible. 

1 .3  Architecture  Approach 

The  methodology  specified  in  the  DoD  Standards-Based  Planning  Handbook 
was  used  to  develop  this  architecture  and  its  supporting  documents.  The 
approach  includes  the  following: 

1.  Adopting  the  DoD  Technical  Architecture  Framework  for 
Information  Management  as  the  framework  and  vision  for  the  Finance 
Architecture.  The  Technical  Architecture  Framework  provides  the 
foundation  and  template  for  the  Finance  Architecture. 

2.  Developing  a  Finance  Baseline  which  provides  information  on  the 
.  current  finance  technical  infrastructure. 

3.  Define  a  target  architecture. 

4.  Identifying  areas  for  more  In-depth  analysis.  Teams  were  formed 
to  look  at  these  areas  in  more  detail  using  the  architecture  as  an 
overall  integrating  mechanism. 

5.  Providing  options,  economic  analysis  and  recommendations  on 
migration  alternatives  to  the  finance  community. 

6.  Providing  implementation  guidance  to  the  finance  community 
based  on  the  migration  options. 
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For  more  information  concerning  the  basis  for  adopting  this  approach 
please  refer  to  the  DoD  Technical  Architecture  Framework  for 
Information  Management  and  the  Technical  Reference  Model  for 
Information  Management,  Version  3.0. 


1.4  Scope  of  Near-Term  Technical  Architecture 


This  architecture  consists  of  views  of  the  finance  technical 
infrastructure  that  describe  the  selection  and  configuration  of 
components  at  different  points  in  time.  These  time  frames  represent  a 
migration  path  (Figure  1-1)  from  legacy  systems  to  migration  systems 
and  eventually  to  objective  systems  conforming  to  all  applicable  DoD 
standards  and  guidelines.  No  explicit  dates  are  given  for  when  the 
migration  occurs.  At  any  given  point  in  time,  an  individual  system  may  be 
in  any  of  the  three  phases.  The  eventual  goal  is  to  move  all  systems  to  the 
objective  environment. 


Page  3 


In  following  this  migration  path,  the  finance  community  needs  to 
categorize  the  support  applications,  platforms,  and  communications 
components  to  indicate  which  ones  should  be  considered  in  making 
technology  investments.  By  having  an  explicitly  defined  set  of  categories 
of  components,  optimal  technical  decisions  can  be  made  at  each  point 
within  the  migration.  The  technologies  and  components  that  define  the 
architecture,  either  in  the  current  inventory,  or  where  procurement  is 
required,  will  be  placed  in  one  of  the  following  categories  (Figure  1-2): 


FIGURE  1-2:  MIGRATION  PATH  CATEGORIES 


GREEN  ••  contains  ail  those  components  that  conform  to  applicable 
DoD  standards  and  guidelines.  Every  effort  should  be  made  to  use 
products  in  this  category  unless  economic  analysis  or  product 
availability  makes  it  impossible. 

YELLOW  -  contains  all  those  components  that  do  not  meet  the 
applicable  DoD  standards  and  guidelines,  but  represent  a  choice  to 
achieve  technical  integration.  Yellow  components  are  used  because 
of  compelling  economic  or  functional  reasons  and  more  closely  align 
with  the  applicable  standards  and  guidelines.  Where  possible,  this 
category  takes  advantage  of  the  current  technology  inventory  to 
avoid  additional  capital  investment. 

RED  -  contains  all  those  components  used  by  legacy  and  migration 
systems  that  do  not  follow  the  desired  migration  path.  It  may  be 
required  to  use  some  components  in  this  category,  but  only  under 
exceptional  circumstances. 

Figure  1-3  shows  the  migration  time  frames  and  relates  it  to  the 
component  categories.  In  the  legacy  time  f.^ame,  red,  yellov/  and  green 
components  may  exist  in  individual  systems.  In  the  consolidation  time 
frame  the  move  is  to  eliminate  red  components.  In  the  objective  phase  the 
move  is  towards  systems  that  use  green  components  to  tiie  maximum 
extent  possible. 


1.5  Document  Organization 

The  Finance  Near-Term  Technical  Architecture  consists  of  three  chapters 
and  two  appendices.  Chapter  2  specifies  the  architecture  structure  and 
includes  migration  analysis  and  guidance.  Chapter  3  provides  overall 
Implementation  concepts.  Definitions  and  acronyms  are  in  Appendices  A 
and  B,  respectively. 

[Note:  This  version  does  not  include  ait  sections  of  Chapter  2 
and  the  Appendices.  These  will  be  included  in  future  versions.] 


2.0  ARCHITECTURE  STRUCTURE 
2.1  Overview 

The  architecture  structure  provides  the  basic  concepts  that  will  govern 
the  evolution  of  the  Finance  Technical  Infrastructure.  This  structure 
defines  the  layers  of  the  Finance  Technical  Architecture,  the  common 
services  provided  by  each  of  the  layers,  the  relationships  between  the 
layers  and  establishes  the  rules  for  how  they  are  interconnected. 

A  more  general  discussion  of  the  concepts  of  architectural  layers, 
services,  and  components'  can  be  found  in  the  DoD  Technical  Architecture 
Framework  for  Information  Management,  Volume  2,  Architecture 
Guidelines  and  Design  Concepts. 

The  Finance  Technical  Architecture  Structure  is  comprised  of  three 
layers,  support  applications,  platforms,  and  communications,  each  layer 
providing  specialized  services. 

0  Support  application  services  provide  services  that  are  not 
available  as  platform  services.  These  applications  are  implemented 
.  primarily  in  software  and  include  applications  such  as  E-Mail,  word 
processors,  and  spreadsheets. 

0  Platform  layer  services  provide  the  common  information 
processing  and  communications  functions  required  by  the  Finance 
and  Accounting  functional  area.  A  platform  is  made  up  of  a 
processor,  peripherals,  and  software  that  implements  platform  layer 
services.  The  platform  also  includes  communications  network 
services  that  are  provided  to  applications  through  an  Application 
Program  Interface  (API). 
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0  Communications  layer  services  provide  end-to-end 
communications  among  platforms.  These  services  are  provided  to 
platforms  through  an  External  Environment  Interface  (EEI).  The 
communication  layer  includes  communications  devices  such  as 
routers  and  gateways  and  the  software  required  to  implement 
communications  services. 

While  the  Finance  Technical  Architectural  structure  does  not  include  the 
framework  for  organizing  and  defining  the  interrelationships  of  data,  it 
does  provide  the  services  needed  to  manage,  fc^nat,  and  exchange  data. 
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2.2  Support  Applications 

Support  Applications  are  generic  applications  that  provide  common 
communication  and  information  processing  services  to  users  and  other 
applications.  Support  applications  supplement  the  services  offered  by 
the  platform  to  satisfy  general  functional  needs.  In  some  cases,  support 
applications  provide  common  services,  such  as  word  processing,  not 
offered  by  the  platform.  In  other  cases,  such  as  E-Mail,  support 
applications  coordinate  the  use  of  platform  services  and  present  them  to 
users  ar^d  other  applications  in  an  organized,  easy  to  use  manner. 

Support  I  applications  simplify  the  computing  and  communications 
environment  for  mission  area  applications  and  users  by  insulating  them 
from  the  technical  details  of  the  computing  and  communications 
infrastructure.  This  insulation  also  promotes:  the  portability  of  users  and 
mission  jarea  applications:  the  integration  of  new  technology  into  existing 
environrrients;  and,  the  distribution  of  platform  services  based  on 
functional  requirements  and  processing  efficiency. 

This  initai  section  on  support  applications  has  been  limited  to  those 
support  applications  identified  through  DFAS  functional  requirements  as 
near  terln  priorities.  The  description  of  each  support  applications 
includes  a  brief  summary  of  the  existing  baseline  capability  if  one  exists. 
Migration  analysis  and  guidance  is  provided  to  support  both  the  near  term 
finance  and  accounting  consolidation  efforts  as  well  as  long  range  DoD 
objectives  to  establish  an  open  distributed  computing  environment.  Each 
section  also  includes  a  list  of  applicable  standards. 
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2.2.1  Imaging 


To  be  provided  in  Version  2.0 
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2.2.2  Transaction  Processing 

2.2.2.1  Durrent  Transaction  Processing  Environment 

The  current  DoD  transaction  processing  environment  is  characterized  by 
batch  and  interactive  query  and  update  transactions  against  data  managed 
by  a  DBMS  or  a  file  system.  The  interactive  transactions  are  primarily 
managed  by  teleprocessing  (TP)  monitors  associated  with  a  specific  data 
base  ususHy  in  a  one  to  one  relationship.  Complex  queries  and  batch 
updates  s  re  typically  processed  during  non-peak  hours.  There  is  little 
sharing  o  data  or  integration  betwee.i  systems,  and  users  requiring  data 
from  more,  than  one  data  base  are  required  to  logon  to  separate  systems. 
The  follo'iving  list  shows  the  diversity  of  the  TP  monitors  associated  with 
the  legacy  and  migration  systems. 

2.2.2.2  Analysis  and  Guidance 

The  long  range  objective  of  the  DoO  is  to  establish  a  distributed 
computing  environment  where  transaction  processing  services  are  used  to 
support  transparent  access  to  distributed  processes  and  databases 
anywhere  in  the  network.  In  this  environment,  a  single  transaction 
processor,  or  multiple  transaction  processors  capable  of  interoperating, 
will:  manage  access  to  all  of  the  available  processes  and  databases;  will 
be  capable  of  infiraction  with  diverse  application  and  platform  services 
on  multiple  hardware  and  software  platforms;  be  accessible  from  all 
nodes  in  the  DoD  computing  and  conimunication  infrastructure;  be  able  to 
manage  the  invocation  of  any  combination  of  local  and  remote  processes; 
and,  be  compliant  with  open  system  standards. 

During  the  consolidation  phase,  the  migration  to  the  objective  transaction 
processing  environment  will  proceed  along  two  paths.  The  first  path  will 
be  to  standardize  on  no  more  then  three  TP  monitors  from  the  migration 
system  baseline.  One  each  to  support  the  existing  migration  applications 
in  the  IBM,  UNISYS,  and  Data  General  environments. 
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During  the  consolidation  phase,  the  common  mainframe  TP  monitors  will 
not  be  required  to  meet  the  standards  set  forth  in  the  DoD  Technical 
Architecture  Framework  for  Information  Management.  Once  the 
consolidation  phase  is  accomplished,  there  will  be  a  concerted  effort  to 
migrate  transaction  management  away  from  proprietary  environments.  If 
there  Is  a  continued  need  for  a  mainframe  TP  monitors,  they  will  be 
required  to  support  the  distributed  transaction  processing  standards  that 
are  currently  emerging,  so  that  they  can  accept  transactions  from 
application  processes  and  transaction  managers  that  are  distributed  to 
other  platforms. 

The  second  path,  which  can  occur  simultaneously  with  the  first,  involves 
the  establishment  of  the  objective  transaction  processing  environment. 

The  first  step  will  be  to  standardize  on  a  transaction  manager  (processor) 
targeted  for  the  objective  POSIX  environment  that  meets  the  requirements 
set  forth  In  the  DoD  Technical  Architecture  Framework  for  Information 
Management  and  the  applicable  standards  listed  in  section  2.2.2.3. 

A  key  distinction  between  the  traditional  TP  monitor  environment  and  the 
objective  transaction  processing  environment  lies  In  the  way  they  handle 
the  three  main  pieces  of  transaction  processing;  transaction  management, 
resource  management  (typically  data),  and  communications.  In  the 
traditional  TP  monitor  environment,  the  TP  monitor  is  tightly  coupled 
with  a  database  manager  and  the  underlying  communications  necessary  to 
support  remote  users.  In  the  objective  transaction  processing 
environment  there  is  a  separation  of  the  management  of  transactions  from 
the  management  of  resources  (data)  and  the  communications  required  to 
support  them.  This  separation  of  function  promotes  the  establishment  of 
a  distributed  computing  environment  where  transaction  processing 
functions  can  be  isolated  and  distributed  to  appropriate  locations,  and 
users  can  be  anywhere  In  the  network.  As  the  objective  transaction 
matures  it  is  imperative  that  these  boundaries  be  maintained. 

During  the  consolidation  phase,  an  initial  implementation  of  the  standard 
transaction  manager  can  be  used  to  direct  queries  to  DBMSs  managing 
redundant  copies  of  migration  application  data  that  have  been  downloaded 
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to  POSIX  compliant  platforms.  As  new  applications  are  developed,  or  as 
migration  application  processes  are  re-engineered  to  access  and  update 
data  managed  in  a  POSIX  compliant  environment,  the  standard  transaction 
manager  can  be  used  to  control  their  transactions. 

Interoperability  between  the  objective  transaction  manager  environment 
and  the  mainframe  TP  monitors  can  be  established  to  support  distributed 
users  and  processes  that  need  real-time  access  to  data  managed  by 
mainframe  migration  application  DBMSs.  This  interoperability  will  be 
provided  with  an  interface  that  conforms  to  the  mainframe  protocols. 

Over  time,  as  different  resource  managers  (file  servers,  DBMS,  application 
servers,  etc)  are  established  on  the  network,  the  standard  transaction 
manager  can  be  used  to  route  work  to  the  appropriate  server  and  begin  to 
control  the  flow  of  transactions  in  a  distributed  transaction  processing 
environment.  Figure  2-1  provides  the  migration  path  for  transaction 
processing. 
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FIGURE  2-1:  TRANSACTION  PROCESSING  MIGRATION  PATH 
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■2.2.2.3  Applicable  Standards 

The  following  standards  apply  to  transaction  processing: 

-  POSIX  1003.11  -  Transaction  Processing 

-  ISO  TP  -  International  Standards  Organization  Transaction 
Processing 

-  X/Open  XA  -  a  standard  interface  between  relational  DBMSs  and 
transaction  processing  systems. 

-X/OpenTM 
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2.2.3  Video  Teleconferencing 

2.2.3.1  Current  Video  Teleconferencing  Environment 

DFAS  Is  currently  Implementing  a  video  teleconferencing  capability  (VTC) 
at  the  following  locations: 

•  HQ  DITSO,  Denver.  CO 

•  HQ  DFAS,  Arlington.  VA 

•  Columbus  Center,  Columbus,  OH 

•  Cleveland  Center,  Cleveland,  OH 

•  Indianapolis  Center,  Indianapolis,  IN 

•  Kansas  City  Center,  Kansas  City,  MO 

•  Denver  Center,  Denver,  CO 

•  Cleveland  Center  Satellite  at  Pensacola,  FL 

In  addition,  the  existing  VTC  system  at  Denver  will  be  upgraded  and 
replicated  at  Pensacola. 

The  HQ  DITSO  location  is  a  GSA/FTS  2000  Network  A  subscriber.  This 
permits  the  HQ  DITSO  node  to  dial,  via  switched  service,  directly  to  the 
Director  of  Defense  Information  (DDI)  at  the  Pentagon,  the  DISA/CIM  node 
In  Vienna,  VA,  and  the  DISA  Multipoint  Control  Unit  at  DISA  Headquarters. 
Connection  to  the  DISA  Multipoint  Control  Unit  permits  both  multipoint 
and  point-to-point  conferencing  with  existing  DISA  Video  Conferencing 
subscribers  at  HQ  DISA  in  Arlington,  VA,  Virginia  Square  in  Arlington,  VA, 
and  Isaac  Newton  Square  in  Reston,  VA. 

Currently,  video  teleconferencing  services  are  available  for  over  110 
rooms  which  can  confer  with  other  users  In  either  a  point-to-point  or 
multipoint  mode.  Users  of  these  services  Include  the  Navy,  Army,  Air 
Forces,  the  Strategic  Defense  Initiatives  Organization  (SDIO),  and  Forces 
Command,  along  with  major  defense  contractors  and  other  Government 
agencies.  Gateways  to  Sprint’s  Meeting  Channel  and  AT&T’s  Accunet 
Reserved  Digital  Services  allow  for  meetingc  with  other  national  and 
international  facilities  connected  to  these  networks. 


2.2.3.2  Analysis  and  Guidance 

Video  teleconferencing  is  a  means  of  communicating  between  two  or  more 
groups  of  individuals  in  different  locations  using  interactive  video  and 
audio  to  provide  the  equivalent  of  a  face-to-face  meeting.  Video 
teleconferencing  is  implemented  by  a  variety  of  methods:  cus*  mized 
video  teleconferencing  rooms  with  specialized  acoustics  and  lighting; 
smaller  roll-about  conference  room  systems;  and  PC-based  desktop  video 
teleconferencing  worKStations. 

Each  method  satisfies  a  different  set  of  requirements,  has  its  strengths 
and  weaknesses,  and  provide  varying  degrees  of  video  and  audio  quality. 
Facilities  are  connected  by  either  dedicated  digital  lines  and/or  switched 
digital  services.  Standard  communication  interfaces  include  ISDN,  using 
both  the  Sasic  Rate  Interface  (BRI)  and  the  Primary  Rate  Interface  (PRI). 
Most  systems  are  connected  through  dedicated  digital  lines  running  at 
speeds  between  56  Kbps  and  1.544  Mbps  (the  maximum  pi-ovided  by  T1 
circuitry.)  Standard  communication  interfaces  include  T1,  fractional  T1, 
T3.  and  switched  56  Kbps  services.  NOTH:  56Kbs  is  not  recommended 
for  video  teleconferencing  because  of  insufficient  bandwidth. 
Many  of  these  conferences  occur  between  only  two  rooms,  while  others 
are  connected  through  a  Multipoint  Control  Unit  (MCU)  to  allow  for  more 
than  two  sites  to  confer  at  a  time. 

Outside  of  the  standard  video  and  audio  capability,  additional  features 
which  can  be  available  include: 

•  FAX  -  documents  can  be  faxed  during  a  conference. 

•  Graphics  -  Photos,  graphs,  color  slides,  etc.,  can  bo  captured  by 
a  special  camera  and  transmitted  during  a  conference. 

•  PC  Images  -  PC  graphs,  documents,  and  mainframe  computer 
sessions  can  be  transmitted  during  a  conference. 
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Telephone  bridges  -  These  devices  can  be  used  to  tie  outside 
phone  conversations  into  an  active  video  teleconference. 


The  customized  video  teleconferencing  room  has  been  the  main  form  of 
videoconferencing  throughout  the  1980’s.  These  rooms,  costing  up  to  $1 
million  per  site,  must  be  specifically  designed  and  engineered  to  provide 
the  best  audio  and  video  performance  for  an  effective  conference.  They 
are  usually  connected  by  T1  or  fractional  T1  dedicated  communication 
lines.  Faxes,  telephone  bridges,  multiple  camera  shots,  PC  and  overhead 
graphics,  as  well  as  customized  control  panels  can  be  included  in  the  room 
package  and  help  to  contribute  to  a  successful  conference. 

Roll-about  cabinet  systems  have  been  introduced  in  the  last  few  years  and 
hav3  become  very  popular  because  of  their  lower  cost  (between  $20,000 
and  $150,000)  and  their  ability  to  be  used  in  a  variety  of  areas.  With  the 
improvements  in  audio  and  video  technology,  perfect  room  acoustics  and 
lighting  are  no  longer  required  to  provide  quality  meetings.  The  cabinets 
usually  come  with  video  monitors  and  can  include  such  features  as  fax. 


Desktop  video  conferencing,  implemented  using  PC-based  multimedia 
systems,  is  the  most  recently  developed  method  to  provide  video 
teleconferencing.  These  systems,  costing  between  $5,00C  and  $7,000,  are 
.connected  via  communication  services  provioed  either  by  an  ISDN  or  a 
switched  53  Kbps  network.  These  facilities  allow  the  users  to 
communicate  face-tc-face  in  a  window  on  their  PCs  and  to  exchange  PC- 


type  data  such  as  spreadsheets,  documents,  and  graphics.  Most  existing 
LANS  can  not  adequately  support  VTC  due  to  the  high  bandwidth  required. 
The  advent  of  higher  bandwidth  LANS,  implemented  using  Fiber  Distributed 
Data  interface  (FDDI)  or  Asynchronous  Transfer  Mode  (ATM)  technology, 
along  with  future  improvements  in  video  compression  algorithms,  should 
allow  for  VTC  on  LANs  to  become  more  common  place.  I 


The  type  of  facility  selected  during  the  consolidation  and  objective  p'aij 
phases  will  be  determined  by  user  requirements  and  budget  constraints. 
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2.2.3.3  Applicable  Standards. 

The  DoD  standard  for  compressed  digital  video  teleconferencing  is  MIL- 
STD-188-121.  This  standard  is  still  In  development  and  awaits  testing 
and  publishing.  Final  approval  and  testing  is  expected  in  early  1994. 
Meanwhile,  DoD  facilities  should  comply  with  CCITT  international 
standards.  The  current  overall  standard  for  VTC  is  CCITT  H.320. 
Standards  referenced  include: 


H.320 

H.221 

H.230 

H.231 

H.242 

H.261 

G.711 

G.722 


Overall  standard  ths  Involves  other  standards 
Frame  Structure  and  Signalling 
Control  and  Indication  Signals 
Multipoint  Control  Units  for  Audiovisual 
Systems 

Establishing  Communications 
Coding  of  the  Video  Signal 
Narrow  band  (3KHz)  speech  at  64  Kbps 
Wideband  (7KHz)  speech  at  64  Kbps 
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2.2.4  Interactive  Voice  Response 
2.2.4. 1  Current  Environment 

interactive  Voice  Response  (IVR)  is  a  new  technology  which  allows 
service  members  direct  access  to  general  information  about  retirement  or 
military  pay  operations  or  specific  information  concerning  their 
individual  account.  Selected  data  ^elds  for  each  account  holder  reside  on 
the  Interactive  Voice  Response  System  (IVRS)  mini-computer.  Account 
holders  receive  a  Personal  Identification  Number  (PIN)  which,  in 
combination  with  their  Social  Security  Number,  give  them  access  to  the 
data  in  the  IVRS  through  any  touch-tone  phone.  The  system  also  allows 
account  holders  to  leave  or  receive  voice  messages.  Using  a  telephone 
keypad  as  a  terminal,  the  user  can  extract,  input,  or  manipulate  data 
stored  on  the  computer.  The  definition  of  IVR  is  expanded  to  include  the 
use  of  speech  recognition  as  the  input  device  to  the  voice  response  unit 
(VRU)  which  converts  the  digital  information  to  voice  (analog)  and  speaks 
it  back  to  the  caller.  Speech  recognition  provides  users,  who  do  not  have 
access  to  a  touch-tone  telephone,  the  ability  to  speak  into  a  telephone  to 
input  and  retrieve  information  from  a  computer. 

IVR  greatly  Increases  the  productivity  and  capabilities  of  the  customer 
service  divisions  by  enabling  a  reduced  staff  to  handle  all  incoming 
inquiries..  Additionally,  it  will  provide  interconnectivity,  expansion 
capability,  and  be  able  to  interface  with  other  advanced  technologies  such 
as  Electronic  Data  Interchange  (EDI).  Routine  calls  will  be  processed  by 
the  IVR  equipment,  using  its  round-the-clock  automated  response 
capability.  Callers  will  be  able  to  get  answers  to  routine  questions  about 
their  accounts  by  pressing  buttons  on  their  touch-tone  telephones, 
without  the  Intervention  of  customer  service  agents.  The  interface  with 
EDI  can  provide  copies  of  W-2s  or  Leave  and  Earning  Statements  to 
customers  without  the  Intervention  of  DFAS  employees. 
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2.2.4.2  Analysis  &  Guidance 

The  IVR  must  be  completely  controllable  from  a  remote  location  by  means 
of  dial-up  modem.  Application  development  and  maintenance  must  be 
available  remotely.  System  monitoring  and  administrative  management 
must  also  be  remotely  accessible,  the  IVR  system  should  function  without 
the  need  for  on-site  administration.  The  system  is  being  developed  in 
conjunction  with  the  DFAS  Strategic  Transition  Plan  23-2  "Interactive 
Voice  Response  System"  (STP  23-2)  and  Strategic  Transition  Plan  4-1-1 
"Defense  Retired  and  Annuitant  Pay  System"  (STP  4-1-1).  The 
requirements  for  the  system  are: 

0  The  IVR  system  will  be  niterfaced  to  the  DFAS-CL  LAN  and 
mainframe  networks  via  IEEE  802.5  LAN  protocols  and  3270  terminal 
emulation  software.  The  system  must  interface  with  the  IBM 
370/90  architecture  and  current  telephone  hardware  configuration 
(GSA  controlled  CENTREX  using  an  AT&T  5ESS  switch)  and  all  major 
telecommunications  vendors’  current  Automatic  Call  Distributor 
(ACD)  products/services. 

0  Software  to  develop  IVR  applications  must  be  capable  of 
interacting  with  live  host  applications  to  facilitate  rapid 
development.  IVR  software  must  be  menu  driven  for  script 
development.  No  changes  to  host  applications  must  be  required  to 
run  the  IVR  application. 

0  Voice  recognition  must  be  provided  for  all  72  lines.  Spoken 
vocabulary  must  include  the  numbers  "zero"  through  "nine",  "Yes",  and 
•No". 

0  The  IVR  must  be  capable  of  72  simultaneous  on-line  host  sessions. 
Shared  host  connections  for  multiple  incoming  lines  is  not 
acceptable. 
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0  Each  IVR  line  must  be  capable  of  interfacing  with  a  fax  module 
which  can  generate  fax  messages  directly  from  host  application 
reports,  from  host  information  combined  with  disk-based  graphic 
forms,  or  from  information  stored  directly  on  the  IVR  disks. 

0  Access  to  the  iVR  maintenance  and  system  administration 
functions  must  be  password  protected. 

2.2.4.3  APPLICABLE  STANDARDS 

There  are  no  standards  documented  for  IVR  technology  at  this  time. 
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2.2.5  Electronic  Data  Interchange 

Electronic  Data  Interchange  (EDI)  is  the  electronic  exchange  of  business 
transactions  formatted  in  accordance  with  a  public  standard.  While  there 
are  many  different  issues  involved  in  establishing  an  EDI  capability,  two 
of  the  key  technical  elements  include  standardizing  the  formats  of 
business  transactions  and  standardizing  the  communications  between 
business  partners. 

2.2.5.1  Current  Environment 

EDI  is  being  used  at  some  locations  to  support  Electronic  Funds  Transfer 
with  the  banking  industry  however,  the  majority  of  the  business 
transactions  in  the  current  Finance  and  Accounting  environment  are  still 
being  conducted  via  paper.  Those  finance  applications  that  do  support  the 
electronic  exchange  of  business  transactions  do  not  conform  to  a  piiiblic 
standard  such  as  XI 2  or  EDIFACT.  As  a  result,  these  applications  require 
DoD  business  partners  to  format  business  transactions  differently.  In 
addition,  a  wide  variety  of  communication  methods  are  being  used,  once 
again  requiring  DoD  business  partners  to  support  many  different 
communication  methods. 

2JL5.2  Analysis  and  Guidance 

The  objective  EDI  environment  is  a  single  interface  where  all  business 
transactions  are  formatted  into  X12  or  EDIFACT  and  are  transmitted  in 
accordance  with  X.435,  the  emerging  standard  that  merges  X.400  and  EDI. 

The  primary  goal  for  the  consolidation  phase  is  to  put  an  EDI  support 
application  in  place  that  can  manage  an  orderly  migration  from  the 
existing  non-standard,  mostly  paper  environment,  to  the  objective 
environment.  To  minimize  impact  on  existing  migration  and  legacy 
applications,  this  support  application  will  shield  mission  area 
applications  from  both  formatting  and  communications  details.  EDI 
support  applications  will  accept  transactions  from  mission  applications 


and  invoke  the  platform  formatting  service  that  will  put  the  transaction 
into  the  appropriate  EDI  format  (see  Section  2.3.5).  When  EDI  transactions 
are  received  from  DoD  business  partners,  the  EDI  support  application  will 
invoke  the  platform  formatting  service  to  take  it  out  of  EDI  format. 
Communications  between  the  mission  application  and  the  EDI  support 
application  and  between  the  EDI  support  application  and  the  platform 
service  will  be  via  will  defined  Application  Program  Interfaces  (APIs). 

The  EDI  support  application  will  also  manage  the  archival/retrieval  of 
these  electronic  transactions. 

Initially,  the  EDI  support  application  will  be  required  to  support  a  wide 
variety  of  communication  media,  including  paper,  SMTP,  FTP,  RJE,  and 
asynchronous  communications.  The  EDI  support  application  will  choose 
the  appropriate  communication  media  required  to  transmit  the  transaction 
to  a  specific  business  partner.  The  migration  to  the  objective 
environment  will  occur  over  time  and  it  will  be  dictated  by  both  emerging 
technology  and  the  capability  of  DoD  business  partners  to  support  EDI. 

Until  the  objective  environment  is  achieved,  the  support  application  will 
need  to  support  most  of  the  above  communication  media. 

2.2.5.3  Applicable  Standards 

There  are  no  international,  national,  or  Federal  standards  that  apply  to  EDI 
support  applications.  The  emerging  standards  in  this  area  all  apply  to 
platform  services,  which  are  addressed  in  section  2.3.5  Data  Interchange. 
The  Information  Exchange  System  (INX)  is  currently  being  used  in  the 
finance  and  accounting  community  as  an  electronic  invoicing  prototype. 

This  system  satisfies  most  of  the  above  criteria  for  support  applications 
and  is  in  the  DoD  Reuse  Library.  The  INX  system  and  other  potential  EDI 
support  applications,  including  the  system  being  developed  as  part  of  the 
Dob  Electronic  Commerce  Program,  need  to  be  evaluated  as  to  which  best 
satisfies  the  EDI  support  application  requirements  for  finance  and 
accounting. 
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2.2.6  Expert  Systems 

2.2.6.1  Current  Expert  Systems  Environment 

DFAS  has  developed,  and  put  into  operation,  several  expert  systems  based 
on  artificial  intelligence  concepts.  These  systems  were  developed  by 
functional  knowledge  engineers  as  well  as  domain  experts.  VP-Expert  and 
1st-Class  are  the  selected  PC  software  tools  running  on  an  IBM 
compatible  hardware  platform.  These  systems  support  the  Survivor 
Benefit  Plan,  Social  Security  Offset  Plan,  Employee  Leave  Policy,  Former 
Spouse  Survivor  Benefit  Plan,  Basic  Allowance  for  Quartern  (BAQ)  for 
Secondary  Dependency,  and  PC  Diagnostics.  DFAS  is  pursuing  the 
development  and  implementation  in  both  the  PC  and  mainframe 
environments. 

2.2.6.2  Analysis  and  Guidance 

Analysis  and  guidance  will  be  provided  in  a  future  version. 
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2.2.7  Office  Automation 


To  be  provided  a  future  version. 


2.3  Platform 


The  platform  provides  common  processing  and  communications  services  as 
identified  by  the  Tachnica!  Reference  Model  for  Information  Management, 
the  DoD  Technical  Architecture  Framework  and  the  POSIX  Open  Systems 
Environment  Guide.  These  services  are  provided  to  users,  mission  area 
applications,  and  support  applications  and  are  satisfied  through  a 
combination  of  hardware  and  software. 

Platform  hardware  includes  a  processor  and  all  devices  external  to  the 
processor  required  to  support  users,  external  data  storage,  and  data 
interchange.  External  devices  include,  among  others,  CRTs,  keyboards, 
mice,  floppy  disks,  and  disk  drives.  Hardware  specific  to  communications 
is  also  considered  to  be  an  external  device,  but  these  devices  are  covered 
under  communications. 

Platform  software  implements  platform  services  and  includes  the 
Application  Program  Interface  (API)  that  allows  applications  to  invoke 
platform  services  as  well  as  the  External  Environment  interface  (EEI)  that 
enables  communication  between  the  platform  and  external  devices. 

The  initial  version  of  this  section  contains  a  discussion  of  the  platform 
services  deemed  to  be  the  most  critical  to  the  finance  and  accounting 
community.  Each  of  the  discussions  Includes  a  brief  summary  of  the 
existing  baseline  environment.  Migration  analysis  and  guidance  is 
provided  to  support  both  the  near  term  finance  and  accounting 
consolidation  efforts  as  well  as  long  range  DoD  objectives  to  establish  an 
open  distributed  computing  environment.  Each  section  also  includes  a  list 
of  applicable  standards. 
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2.3.1  Operating  Systems 

2.3.1. 1  Current  Operating  System  Environment 

The  operating  systems  for  the  current  legacy  and  migration  systems  are 
as  follows: 


Legacy  Systems  Migration  Systems 


NAVSCIPS 

MVS-XA 

DCPS 

MVS-XA 

NAFCPS 

MVS 

OS1100 

JUMPS-JSS 

MVS-XA 

OJMS 

MVS-XA.  MPE/V 

MCARS  I 

MVS-XA 

DRAS-NRPS 

MVS-XA 

DRAS 

MVS-XA 

AFAPS 

MVS-XA 

DTPS-ATOS 

MSDOS 

DTPS 

DGAJX 

lATS 

MSDOS 

TRIPS 

MS-DOS 

DTRS-TIPS 

UNISYS 

DTRS 

OS1100 

MOCAS 

MVS-XA 

MOCAS 

MVS-XA 

AFDARS 

MVS 

DDMS 

MVS-XA 

APCAPS 

MVS 

DRMS 

MVS-XA 

2.3.1 .2  Analysis  and  Guidance 

The  long  range  DoD  objective  for  operating  systems  is  compliance  with 
the  POSIX  suite  of  standards  as  defined  in  FIPS  PUB  151-1.  POSIX 
compliant  operating  systems  provide  a  set  of  common  services  which  can 
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be  used  to  improve  application  portability  and  interoperability.  Any  POSIX 
compliant  operating  system  that  meets  the  information  processing 
requirements  of  the  finance  and  accounting  community  is  acceptable. 

The  objective  for  mainframe  operating  systems  during  consolidation  is  to 
minimize  legacy  system  diversity  and  establish  a  stable  baseline.  This 
can  be  accomplished  by  selecting  operating  systems  from  the  existing 
legacy  baseline.  The  near-term  goal  should  be  standardization  on 
proprietary  operating  systems  given  their  dominance  in  the  existing 
baseline. 

The  most  prevalent  mainframe  operating  system  in  the  current  installed 
base  of  migration  systems  is  MVS  and.  therefore,  is  selected  as  the 
perfered  operating  system  for  standardization  during  the  consolidation 
phase.  This  includes  MVS-XA  and  MVS-ESA.  During  consolidation  the 
advantages  of  continuing  to  use  the  current  MVS-based  systems  ouhveigh 
any  movement  towards  POSIX  due  to  the  current  investment  in  MVS  and 
compatible  hardware  and,  the  re-engineering  effort  required  to  transition 
the  current  environment  to  POSIX.  By  standardizing  on  MVS,  the  migration 
systems  applications  will  be  able  to  execute  and  share  resources  at 
multiple  processing  locations. 

OS1100,  DG/US,  and  MVP/E  are  also  placed  in  the  yellow  category  during 
consolidation.  These  operating  systems  represent  a  significant  current 
investment  in  the  finance  community  and  the  effort  required  to  re¬ 
engineer  these  to  the  standard  OS  be  prohibitive  in  the  near-term. 

UNIX  Non-POSIX  operating  systems  are  placed  in  the  yellow  category  for 
the  consolidation  phase  since  these  provide  the  functionality  required  to 
implement  the  client/server  approach  and  provide  a  transition  path  to 
POSIX 

In  the  microcomputing  environment,  DOS  is  the  near  term  choice.  It  is  the 
prevalent  operating  system,  is  an  enabling  technology  during  the 
consolidation  phase,  and  offers  a  large  variety  of  commercial-off-the- 
shelf  (COTS)  software  products. 
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Figure  2~2  provides  the  migration  path  for  operating  systems. 
2.3.1. 3  Applicable  Standards 

The  following  standards  apply  to  Operating  Systems: 


0  IEEE  P1003.1  -  1990  (ISO/IEC  9943-1:1990)  -  Portable  Operating 
System  Interface  for  computer  environments:  POSIX 

0  FIPS  151-1  -  POSIX 

0  FIPS  151-2  -  POSIX 

0  IEEE  PI  003.2  -  Shell  and  Utilities 

0  IEEE  PI  003.4  -  Real  Time  Extensions 

0  IEEE  PI  003.6  -  Security 

0  GNMP/MIL-STD-2045-3800  -  System  Management 


2.3.2  Programming 

2.3.2.1  Application  Program  Language 

2.3.2.1.1  Current  Application  Programming  Language  Environment 
Application  programming  languages  for  the  current  legacy  and  migration 


systems  are  as 

follows: 

Legacy  Systems 

Mioration  Systems 

navsc:ps 

NAFCPS 

COBOL 

coBa 

DCPS 

coBa 

JUMPS-JSS 

MCARS 

COBOL 

ALC.  COBOL,  NATUHAl, 
Easytrieve 

DJMS 

COBOL 

DRAS-NRPS 

AFAPS 

COBOL,  Easytrieve 

ADSO,  COBOL, 

Easytrieve 

DRAS 

coBa 

DTPS  -  ATOS 
Clipper 

lATS 

BASIC 

DTPS 

’C, PROGRESS 
(4GL) 

DTRS-TIPS 

COBOL 

DTRS 

COBOL 

MCOAS 

COBOL,  MANTIS  (4GL) 

MOCAS 

COBOL,  MANTI 
(4GL) 

AFDARS 

ADSO,  COBOL 

DOMS 

COBOL 

APCAPS 

COBOL 

DRMS 

COBOL 
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2.3.2.2.2  Analysis  and  Guidance 

The  objective  application  programming  language  is  a  standard  Computer- 
Aided  Software  Engineering  (CASE)  tool  generated  procedural  language. 
Where  feasible,  Ada  is  required  by  DoD  policy. 

The  objective  for  application  programming  languages  during  consolidation 
is  to  minimize  diversity  and  establish  a  stable  baseline.  COBOL  is  the 
prevalent  language  in  the  current  installed  migration  baseline  and  is 
therefore  the  selection  for  standardization  (green  category)  during  the 
consolidation  phase.  The  applications  should  be  re-engineered,  where 
economically  feasible,  to  standardize  to  the  same  version  of  COBOL85. 
Language  extensions,  if  used,  will  be  modularized  in  order  to  facilitate 
portability.  Language  extensions  will  not  be  allowed  in  re-engineered  or 
newly  developed  code.  CASE  tools  that  generate  COBOL  are  commercially 
available  and  should  be  used  when  modifying  the  legacy  systems. 

Finance  and  accounting  systems  that  upgrade  their  operating  systems 
from  MVS-XA  to  MVS-ESA  will  have  to  migrate  to  COBOL85  with  COBOL89 
addendum  in  accordance  with  FIPS-PUB  21-3. 

ANSI  'C  is  placed  in  the  yellow  category  because  of  its  use  in  the 
installed  base  of  application  systems  and  its  status  as  a  FIPS  standard. 
Fourth-generation  languages  such  as  Mantis  and  Progress  are  included  in 
the  yellow  category  and  possibly  the  green  category  for  personal  level 
customization  only.  ALC  is  acceptable  in  the  yellow  category  because  of 
its  machine  level  and  efficiency  characteristics.  ALC  should  be  used  only 
when  necessary  and  will  be  modularized  to  facilitate  modification  or 
removal.  ALC  will  not  be  allowed  in  any  re-engineered  or  newly  developed 
mission  application  software. 


Figure  2-3  provides  the  migration  path  for  application  programming 
languages.  Languages  listed  in  the  red  category  in  Figure  2-3  do  not 
represent  a  significant  portion  of  the  installed  baseline  and  are  not 
aligned  with  any  national  or  International  standards.  During  the 
consolidation  phase  an  attempt  should  be  made  to  convert  these  languages 
to  ones  listed  In  the  yellow  or  green  categories.  However,  where 
processing  efficiency  dictates  the  use  of  one  of  these  languages  or  where 
they  satisfy  a  unique  requirement,  continued  use  is  acceptable 


FIGURE  2-3:  APPLICATION  PROGRAMMING  LANGUAGES 
MIGRATION  PATH 


2.3.2.1.3  Applicable  Standards 

The  following  standards  apply  to  the  Application  Programming  Languages: 

0  ANSI  2.23-1985  -  COBOL 
0  ANSI  X2.23A-1989  -  COBOL 
0  FIPS  021-3  -  COBOL 
0  ANSI  X2.159-1989  -  ‘C  Language 
0  FIPS  160  -  'C’  Language 
0  POSIX  PI 003.1 6  -  ’C  Language 
0  ANSI/MIL-STD-1815A-1983  -  Ada 
0  FIPS  119 -Ada 
0  POSIX  PI  003.5  -  Ada 
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2.3.2.2  Computer  Aided  Software  Engineering 
2.3.2.2.1  Current  CASE  Environment 


The  current  CASE  environment  consists  of  multiple  non-integrated  tools 
to  provide  system  development  methodologies,  data  repositories,  system 
re-engineering  and  reverse  engineering. 

2.3.2.2.2  Analysis  and  Guidance 

The  long  range  DoD  objective  is  for  a  standard  i-CASE  tool/environment 
utilizing  the  Open  System  Development  (OSD)  technology  to  provide  a 
common  system  development  methodology  across  all  functional  areas. 

This  standard  CASE  environment  will  provide  the  tools  for  data 
repositories,  system  re-engineering  and  reverse  engineering,  and  system 
and  software  life-cycle  management. 

During  the  consolidation  phase,  and  until  the  DoD  standard  I-CASE  tool  is 
available,  the  objective  will  be  to  move  from  the  many  different  tools 
currently  in  use  and  standardize  on  a  single  tool,  PACBASE. 

PACBASE  is  a  suite  of  repository-based  I-CASE  tools  that  support  the 
finance  and  accounting  community  during  the  consolidation  phase,  It  will 
provide  a  standard  procedural  language;  support  the  required  re¬ 
engineering  and  reverse  engineering:  and,  support  the  development  and 
maintenance  of  logical  metadata  repositories. 

2.3.2.2.3  Applicable  Standards 

There  are  no  established  standards  for  CASE  tools/environments  at  this 
time. 
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2.3.3  Network  Services 


2.3.3. 1  Current  Network  Services  Environment 

The  current  legacy  financial  Network  Services  environment  Is  unknown. 
Additional  information  is  required  to  obtain  a  better  understanding  of  the 
DFAS  Network  Services  environment.  Limited  information  available  to 
date  indicates  a  large  percentage  of  the  current  communications 
environment  is  an  IBM  System  Network  Architecture.  For  the  purpose  of 
preparing  the  analysis  and  guidance  section,  typical  IBM  SNA  type  services 
have  been  assumed. 

2.3.3.2  Analysis  and  Guidance 

The  long  range  DoD  objective  for  network  services  is  compliance  with  the 
Government  Open  Systems  Interconnection  Profile  (GOSIP).  DoD  has 
mandated  GOSIP  use  in  all  computer  communications  procurements.  The 
GOSIP  protocols  provide  Interoperability  among  applications  in  a 
heterogeneous  network,  while  the  GOSIP  Application  Programming 
Interfaces  (APIs)  provide  portability  of  applications  across  heterogeneous 
platforms  in  a  network.  GOSIP  is  therefore  placed  in  the  green  category. 

In  the  consolidation  phase,  network  services  will  be  provided  by  multiple 
protocol  stacks.  SNA,  TCP/IP,  GOSIP  and  proprietary  protocols  are 
currently  used  in  the  finance  and  accounting  community  to  provide 
network  services.  The  goals  for  consolidation  are:  elimination  of 
proprietary  protocols,  minimizing  diversity  by  standardizing  on  existing 
standards,  and  providing  a  single  protocol  stack  for  each  processing 
environment. 

In  the  mainframe  environment,  SNA  is  most  commonly  used  to  provide 
network  services,  in  the  consolidation  phase  SNA  is  placed  in  the  yellow 
category.  During  consolidation  the  advantages  of  using  SNA  outweigh  any 
movement  towards  GOSIP  due  to:  the  use  of  SNA  at  most  finance  and 
accounting  mainframe  sites;  the  industry  de  facto  standardization  of  SNA; 
the  hardware/software  availability  of  SNA  products;  and  the  management 
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products  that  exist  for  SNA  environments.  By  standardizing  on  SNA  and 
reducing  the  number  of  protocols,  the  transition  to  GOSIP  in  the 
mainframe  environment  will  be  less  complicated. 

In  the  minicomputer/server  and  workstation  environments,  TCP/IP  is 
placed  in  the  yellow  category  and  should  be  used  during  the  consolidation 
phase.  Wherever  possible  GOSIP  compliant  products  should  be  used.  Due  to 
the  relative  immaturity  of  GOSIP  standards  and  products,  TCP/IP  products 
can  be  used  in  the  near-term.  The  TCP/IP  protocols  provide  services 
similar  to  GOSIP  and  are  open  standards.  If  TCP/IP  is  used,  the  network 
services  calls  should  use  a  standard  interface  which  can  be  linked  to 
GOSIP  network  services  when  they  are  available. 

Figure  2-5  provides  the  migration  path  for  network  services. 
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FIGURE  2-5:  NETWORK  SERVICES  MIGRATION  PATH 


2.3.3.3  Applicable  StanrJards 

0  Government  Open  Systems  Interconnection  Profile  (GOSIP) 

0  NIST  Specification  Pub  500-163 
0  POSIX  1003.8  Networking 
0  POSIX  1003.12  Protocol  Independent  Interfaces 
0  POSIX  1003.17  Directory  Services  API 
0  ISO  Remote  Procedure  Call  (RPC) 

0  X/Open  Application  Program  Interface  Association  (XAPIA) 
oCCITTX.400 

0  CCITT  X.500,  The  Directory,  Overview  of  Concepts,  Models,  and 
Services 

0  Open  Document  Architecture  Office  Document 
0  Interchange  Format  (ODA/ODIF) 

0  OSF  Distributed  Computing  Environment  (DCE) 

-  Andrew  File  System  (AFS) 

0  UNIX  International  (Ul)  Open  Network  Computing  (ONC) 

-  Network  File  System  (NFS) 
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2.3.4  Data  Base  Management 

2.3.4. 1  Current  Data  Base  Management  System  Environment 

The  existing  DBMS  environment  consists  of  a  mixture  of  different 
mainframe  DBMS  products,  PC  based  DBMSs,  and  file  management 
capabilities  provided  by  the  operating  system.  The  mainframe  DBMSs 
provide  a  capability  for  applications  to  access  data  through  a  Structured 
Query  Language  (SQL)  interface  but  few  of  the  applications  use  this 
capability.  The  end  users  are  frequently  supported  through  the  use  of  query 
capabilities  provided  through  proprietary,  non-standard  fourth  generation 
languages  (4GLs)  such  as  Easytrieve,  ADSO,  and  Natural.  These  queries  are 
made  against  production  databases,  and  large  queries  are  frequently 
handled  as  batch  jobs  during  non-peak  processing  times. 

Data  Base  Management  Systems  (DBMSs)  for  the  current  legacy  and 
migration  systems  are  as  follows: 

Legacy  Systems  Migration  Systems 


NAVCIPS 

CA-IDMS/R 

OCPS 

DATACOM  DB 

NAFCPS 

TBD 

JUMPS-JSS 

IDMS 

DJMS 

DB2,  IMAGE,  DMS  1100 

MCARS 

ADABAS 

DRAS-NRPS 

IDMS 

DRAS 

IDMS/R 

AFAPS 

IDMS 

DTPS-ATOS 

TBD 

DTPS 

DBASE  IV,  PROGRESS/R 

lATS 

TBD 

TRIPS 

TBD 

DTRS-TIPS 

DMS  1100 

DTRS 

ORACLE 
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MOCAS 

TIS 

MOCAS 

TIS  (SUPRA) 

AFDARS 

IDMS/R 

DDMS 

TBD 

APCAPS 

TIS, 

DRMS 

SUPRA-II 

2.3.4.2  Analysis  and  Guidance 

The  long  range  objective  for  database  management  systems  is  a  standards- 
based  DBMS  environment  where  subject  databases  provide  information  to 
applications  and  users  regardless  of  location  or  function.  This  standards- 
based  environment  will  be  based  on  relational  database  technology  with 
access  provided  through  the  Structured  Query  Language  (SQL).  Remote 
database  access  will  be  supported  in  compliance  with  the  Remote 
Database  Access  (RDA)  standard.  Users  and  applications  will  be  provided 
transparent  access  to  data  that  will  be  distributed  across  multiple 
hardware  and  software  platforms  located  at  various  nodes  in  the  DoD 
network.  Access  will  be  controlled  through  a  centralized  data 
dictionary/directory  which  will  serve  as  a  repository  of  metadata. 

During  the  consolidation  phase  the  primary  objective  for  database 
management  Is  to  minimize  diversity  in  the  migration  system 
environment,  through  evolution  to  a  SQL  compliant  .relational  DBMS 
environment.  An  attempt  should  be  made  to  standardize  on  one  or  two 
relational  DBMSs  at  each  of  the  three  tiers;  mainframe,  mini,  and  PC.  A 
DBMS  that  runs  on  multiple  tiers  and  platforms,  supports  existing  DBMS 
standards,  and  has  an  announced  migration  path  to  support  emerging  DBMS 
standards,  is  the  best  choice. 

As  licenses  expire  for  existing  migration  system  DBMSs,  acquisitions 
should  attempt  to  procure  a  DBMS  from  the  standard  suite.  New 
acquisitions  and  new  developments  will  require  SQL  compliance.  Major 
enhancements  to  existing  migration  systems  should  use  standard  SQL  with 
a  controlled  use  of  proprietary  extensions.  Where  possible,  existing 
migration  applications  should  be  re-engineered  for  compliance  with  SQL. 
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End-user  query  capabilities  should  be  supported  through  redundant  copies 
of  migration  system  data.  Where  real-time  currency  of  information  is  not 
imperative,  this  redundant  data  could  be  distributed  to  minis  and  PCs. 

This  would  allow  end-users  additional  capability  to  massage  the 
information  without  impacting  corporate  migration  systems  or  data. 
Finance  and  accounting  subject  data  bases  should  be  introduced  during  the 
consolidation  phase.  These  databases  will  be  populated  with  data 
replicated  from  migration  system  DBMSs  and  they  will  be  SQL  compliant, 
initially,  to  minimize  the  impact  on  the  consolidation  process  and  existing 
migration  systems,  these  databases  will  provide  query  only  management 
information  system  capabilities.  Over  time,  create,  delete,  and  update 
capabilities  will  be  added. 

Once  the  finance  and  accounting  consolidations  are  accomplished, 
migration  systems  can  be  re-engineered  and  new  systems  can  be 
developed  to  access  and  update  data  managed  by  the  subject  databases 
Over  time,  ail  database  access  will  be  directed  to  the  subject  databases, 
and  the  migration  databases  will  be  phased  out.  To  minimize  the  imp?  ct 
on  existing  migration  applications,  the  use  of  middleware  tools  that 
intercept  existing  database  access  calls  and  translate  them  into  the 
standard  SQL  calls  expected  by  the  subject  database  may  be  employed. 

New  systems  will  conform  to  the  SQL  standard  Application  Programmin'jj 
Interface  (API).  As  the  standards  for  distributed  transaction  processing 
mature  and  commercial  products  become  available,  the  database 
management  environment  will  be  integrated  into  the  objective  transaction 
processing  environment  (see  Section  2.2.2).  Figure  2-6  provides  the 
migration  path  for  data  base  management  systems. 
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Consctlldation  Systems  Enylronment 

^  _  I  ADAUAC 


lOMS/DB 


Finance 

Standard  DBMS 


'  ADABAS 

!  SUPRA 
I  DATACOM 
I  OB 


IDMS^ 
OB  2 


Legapy  Systems  Environipent 

I  I 

I  TBD  , 

I  I 


ADABASE 
DATACOM  OB 
SUPRA 


FIGURE  2-6:  DATA  BASE  MANAGEMENT  MIGRATION  PATH 


2.3.4.3  Applicable  Standards 

The  following  standards  apply  to  Database  Management  Systems: 

0  FIPS  PUB  127-1  -  Database  Language  SQL 
ANSI  X2. 135-1 989  -  SQL 
ANSI  X2.1 68-1 989  -  Embedded  SQL 
0  FIPS  F’.jB  156  -  Information  Resource  Dictionary  Standard  -  IRDS 
ANSI  X2.1 38-1 988  -  IRDS  Specification 
ANSI  X2.1 95-1 991  -  Import/Export  Format 
o  SQL  Ada  Module  Extensions  -  Sams 
0  Emerging  Standards 

Remote  Data  Access  -  RDA 
Scheme  Manipulation 
Dynamic  SQL 
Exception  Handling 
Enhanced  Integrity  Constraints 
Transaction  Management 
Data  Administration 
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2.3.5  Data  Interchange 

Data  interchange  services  provide  specialized  support  for  the  interchange 
of  data  between  applications  on  the  same  or  different  platforms.  Data 
Interchange  services  include  the  capability  to  exchange  documents, 
graphics,  technical  drawings,  and  standard  business  transactions. 

2.3.5.1  Current  Environment 

There  are  very  few  operational  data  Interchange  platform  services  in  the 
existing  finance  and  accounting  environment.  Some  of  the  existing 
financial  applications  support  Electronic  Funds  Transfer,  but,  for  the  most 
part  this  is  being  accomplished  within  the  financial  applications,  instead 
of  being  handled  as  a  separate  platform  service.  This  mode  of  operation 
requires  that  the  application  be  modified  each  time  that  the  standard 
formats  change  or  as  a  new  format  is  introduced. 

2.3.5.2  Analysis  and  Guidance 

The  objective  environment  for  data  interchange  platform  services  is  one 
which  supports  graphics  data  formats  and  descriptions  as  well  as  data 
format  and  data  description  protocols  for  all  of  the  emerging  ODA,  EDI, 
and  CALS  standards.  The  objective  environment  will  provide  these 
services  on  a  POSIX  compliant  platform. 

During  the  consolidation  phase,  data  interchange  platfoim  services  will 
include  the  capability  to  support  standard  EDI  transactions.  COTS 
translation  software  will  be  used  to  translate  flat  files  into  and  out  of 
EDI  standard  transaction  formats.  Initially,  this  translation  will  occur  on 
a  mid-tier  UNIX  platform.  The  invocation  of  translation  services  will  be 
managed  by  an  EDI  support  application. 

As  Graphical  User  Interfaces  (GUIs)  are  introduced  in  the  finance  and 
accounting  community,  graphics  data  formats  and  descriptions  will  be 
supported.  Platform  services  to  provide  the  necessary  graphics 
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formatting  will  be  introduced  in  both  the  user  workstation  and  mid-tier 
UNIX/POSIX  platforms. 

2.3.5.3  Applicable  Standards 

ISO  8613:1989  -  Office  Document  Architecture/Office  Document 
Interchange  Format/Office  Document  Language  (ODA/ODIF/ODL) 

FIPS  PUB  152  -  Standard  Generalized  Markup  Language  (SGML) 

FIPS  PUB  128  -  Computer  Graphics  Metafile  (CGM) 

FIPS  PUB  150  and  ODA  Raster  Document  Application  Profile  Raster 
Graphics  Representation  in  Binary  Format 

Initial  Graphics  Exchange  Specification  (IGES) 

FIPS  PUB  161  -ASC  XI 2 


FIPS  PUB  161  -  EDIFACT 


FIGURE  2-7:  DATA  INTERCHANGE  MIGARATION  PATH 


2.3.6  Graphics 


To  be  included  in  a  future  version  along  with  Figure  2-8. 
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2.3.7  User  Interface 


2.3.7.1  Current  User  Interface  Environment 

Specific  information  on  the  user  interfaces  in  the  legacy  environment  has 
not  been  collected  and  analyzed  to  the  extent  that  details  can  be  presented 
here.  However,  through  reviewing  the  documented  data  on  the  existing 
hardware  and  software  in  this  environment,  accurate  descriptions  of  the 
user  interface  environment  in  the  Finance  community  may  be  presented 
with  a  large  degree  of  confidence. 

The  largest  population  of  user  interface  in  the  Finance  community  is  the 
3270-type  character-based  Interface.  This  Interface  is  common  among 
the  database  and  transaction  processing  systems  associated  with 
mainframe  financial  applications. 

These  interfaces  were  developed  so  that  character-based  menu  options 
can  be  chosen  or  processing  is  initiated  from  a  command  line  prompt. 

There  is  no  intelligence  required  by  these  terminals  for  this  type  of 
processing:  hence,  3270-type  terminals  prevail  in  the  DoD  Finance 
community. 

The  microcomputer  applications  do  not  use  a  graphical  user  interface 
where  multiple  windows  are  available  concurrently  in  accessing  the 
Rnance  application;  however,  the  applications  may  have  a  combination  of 
”pop-up"  windowing  capability  as  well  as  character-based  menu-driven 
process  initiation. 

Where  there  are  microcomputers  or  PCs  used  for  access  to  the  mainframe 
Rnance  application,  3270-type  terminal  emulation  packages  have  been 
installed.  These  packages  are  generally  TSRs  (terminate  and  stay 
resident)  that  can  be  toggled  via  "hot"  keys  established  in  the  program 
setup.  In  the  Finance  community  where  there  is  a  concurrent  windowing 
capability  on  a  microcomputer,  but  the  application  access  is  via 
3270-type  emulation,  users  are  currently  opening  a  window  to  the 
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I  terminal  emulation  program  and  accessing  the  mainframe  based 
application. 

I  Other  character-based  terminals  such  as  VTIOOs  are  also  used  in  the 
current  legacy  environment  for  access  to  the  Finance  applications.  At 
I  least  one  of  the  systems  In  the  finance  consolidation  environment  Is  using 

t  UNISYS  systems  and  there  are  at  least  h«o  consolidation  finance  systems 

^  that  are  microcomputer  DOS-based  applications. 

The  legacy  system  and  the  migration  system  environment  are: 


Laflagy-Systenis  Migration  Systems 


NAVSCIPS 

NAFCPS 

3270 

3270 

DCPS 

3270 

JUMPS-JSS 

MCARS 

3270 

3270 

DJMS 

3270 

DRAS-NRPS 

AFAPS 

3270 

3270 

DRAS 

3270 

DTPS-ATOS 

lATS 

TRIPS 

PC  Based 

PC  Based 

PC  Based 

DTPS 

PC  Windowing  System 

DTRS-TIPS 

Other  Non-3270 
Character  based 

DTRS 

Other  Non-3270 
Character  based 

MOCAS 

3270 

MOCAS 

3270 

AFDARS 

3270 

DDMS 

3270 

APCAPS 

3270 

DRMS 

3270 
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2.3.7^  Analysis  and  Guidance 

OoO  is  moving  toward  user  interface  services  following  the  guidelines  in 
the  DoD  Human  Computer  Interface  Style  Guide,  Version  1.0.  Objectives  of 
user  Interface  services  are  based  on  the  POSIX  Open  Systems  Environment 
(PI 003.0)  sections  on  Windowing  System  Services,  Character-Based  User 
interface  Services,  and  User  Command  Interface  Services  and  FIPS  Pub 
158  (MIT  X  Window  System). 

The  future  should  include  the  evolution  of  applications  that  have  a  single 
look  and  feel,  a  single  log-on  to  the  system,  multi-media  capabilities, 
manipulation  of  icons  to  process  tasks,  and  human  portability:  that  is,  the 
ability  to  log  on  from  any  location  and  become  productive.  These  topics 
are  covered  extensively  in  the  DoD  Human  Computer  Interface  Style  Guide 
and  In  the  DoD  Technical  Architecture  Framework  for  Information 
Management,  Volume  2.  A  user  interface  style  guide  specific  to  the 
Financial  community,  that  is  based  on  DoD  overall  direction,  will  be 
developed  to  provide  guidance  on  future  development  of  financial 
applications. 

In  the  consolidation  system  environment  where  3270-type  terminals  are 
most  heavily  used,  the  guidance  will  be  to  stay  with  that  architecture,  but 
to  evolve  toward  the  more  open,  user  friendly  interfaces  outlined  in  DoD 
directives. 

As  the  legacy  systems  are  consolidated,  every  attempt  should  be  made  to 
standardize  the  front-end  interface  so  that  there  is  a  common  "look  and 
feel”  among  the  financial  community  systems.  One  option  is  that  there 
will  be  modifications  to  the  character-based  menu  and  command-line 
screen  formats  that  are  currently  implemented  as  user  interfaces  to  the 
Finance  systems  so  that  users  of  the  consolidation  systems  will  be 
presented  with  similar  application  interfaces.  Another  option  is  that  the 
systems  are  consolidated  with  no  new  development  made  to  the  screen 
presentation  formats,  other  than  what  is  necessary  due  to  the 
consolidation  process.  What  is  considered  to  be  the  most  cost  effective 
solution  while  achieving  the  highest  degree  of  standardization  and 
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usability  across  the  Finance  applications  should  be  the  approach. 

During  consolidation,  COTS  software  products  that  allow  the  creation  of 
graphical  user  Interface  presentation  formats  or  "false  fronts"  can  be 
used  with  3270-type  terminal  applications.  This  will  allow  Finance  users 
to  achieve  familiarity  with  icon-based  processing  and  is  a  move  in  the 
direction  of  being  able  to  create  common  "look  and  feel"  interfaces.  For 
the  current  objective  systems,  host-based  application  presentation 
screens  should  not  be  heavily  modified,  other  than  for  the  purposes  of 
consolidation,  and  microcomputer  applications  can  be  developed  as  a  front 
end  to  the  host  Finance  system.  This  microcomputer  application  will 
present  a  common  "look  and  feel"  to  the  user,  but  will  serve  as  a 
collection  point  for  data  that  will  then  be  transmitted  to  the  host 
application  for  processing.  This  interface  to  the  host  application  will  be 
transparent  to  the  Finance  user. 

Further  analysis  pertaining  to  the  cost  effectiveness  and  efficiency  of 
either  of  these  solutions  will  be  performed.  Certainly,  many  alternatives 
exist  that  need  to  be  explored  in  more  detail.  Knowledge  of  other 
functional  area  (i.e.,  Human  Resources,  Medical,  etc.)  user  interfaces  will 
be  important  so  that  in  the  objective  environment,  standardization  of  user 
interfaces  across  all  of  these  functional  areas  will  be  achieved.  The 
Finance  systems  objective  with  regard  to  user  interfaces  is  well 
documented.  The  Finance  systems  need  to  work  with  the  installed  base  of 
technology  through  consolidation.  There  should  be  no  further  development 
of  Finance  applications  that  are  restricted  only  to  3270-type  presentation 
formats.  The  systems  need  to  have  a  Standard  user  interface  style.  Once 
the  standard  is  implemented,  movement  can  be  made  toward  providing 
Finance  users  with  at  least  some  of  the  user  interface  capabilities  that 
will  be  implemented  as  part  of  the  DoD  interface  objective.  Once 
consolidation  is  completed,  efforts  to  re-engineer  the  systems  should  be 
made  to  create  the  objective  system  environment. 

The  migration  path  of  the  current  Finance  environment  as  it  pertains  to 
user  interfaces  will  be  a  standard  presentation  of  character-based 
screens  and  menus  on  3270-type  terminals  or  microcomputers  emulating  a 
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3270-type  terminal.  A  Finance  User  Interface  Style  Guide  will  establish 
the  standards  and  guidelines  that  are  to  be  adhered  to  as  the  migration  and 
consolidation  of  Finance  systems  progresses.  Most  all  of  the 
consolidation  systems  are  mainframe,  MVS.  Cobol  based  systems  that  use 
transaction  processing  facilities.  These  systems  have  traditionally  used 
dumb  terminals. 

There  is  not  going  to  be  a  quick  movement  toward  a  graphical  user 
interface  for  the  Finance  systems.  A  graphical  user  interface  should  only 
be  developed  where  it  is  applicable;  that  is,  when  it  provides  identifiable 
benefits.  Therefore,  the  approach  should  be  to  standardize  the 
configuration  of  the  user  interface  for  the  Finance  systems  according  to 
presentation  (i.e.,  screen  layout,  command-line  options,  etc.)  guidelines. 

The  consolidated  systems  will  evolve  toward  the  DoD  objective  for  all  of 
the  Finance  initiatives  undertaken  in  the  Technical  Architecture.  As  the 
direction  of  the  workstation,  client/server,  and  communications 
initiatives  •  which  are  all  closely  tied  to  the  user  interface  initiative  - 
are  defined  in  more  detail,  movement  toward  graphical  user  interfaces  and 
open  standards  will  be  facilitated.  Figure  2-9  provides  the  migration  path 
for  user  interface. 
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FIGURE  2-9:  USER  INTERFACE  MIGRATION  PATH 
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2.3.7.3  Applicable  Standards 

The  following  standards  and  guidelines  apply  to  user  interfaces: 

0  P1003  -  Guide  to  the  POSIX  Open  Systems  Environment,  ,  (Sections 
on  Windowing  System  Services,  Character-Based  User  Interface 
Services,  and  User  Command  Interface  Services) 

0  FIPS  158  -  User  Interface  Component  of  Applications  Portability 
Profile 

0  Federal  Law  508  -  Americans  With  Disability  Act 
0  DoD  Human  Computer  Interface  Style  Guide 
0  Rnance  Style  Guide  -  To  Be  Developed 
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2.3.8  Security 

2.3.8.1  Current  Security  Environment 

Mainframe  based  legacy  systems  have  been  protected  at  a  C2  Level  of 
Trust  by  a  number  of  software  based  security  packages  affording 
protection  to  data  accessed  primarily  by  dumb  terminals.  Information 
about  systems  running  on  distributed  minicomputers  and  personal 
computers  is  not  available  at  this  time. 

2.3.8.2  Analysis  and  Guidance 

There  will  be  a  continuing  requirement  to  maintain  a  02  Level  of  Trust  for 
Rnance  information  systems  running  at  the  mainframe  sites  and  at  field 
activitiss.  As  the  Information  Processing  Centers  become  more 
standardized  during  migration  system  consolidation,  a  single  software 
package  running  on  the  mainframes  should  be  selected  and  used  by  all  of 
the  IPCs, 

As  local  area  networks  and  intelligent  terminals  become  more  prevalent 
in  Finance  user  work  arer.s,  additional  measures  beyond  the  mainframe 
security  package  must  be  taken  to  maintain  adequate  security.  Multilevel 
security  must  be  put  into  place  in  a  network  environment.  The  access  to 
data  that  interconnected  networks  will  provide  also  increases  the  risk  of 
unauthorized  access  to  that  data.  A  client-server  architecture  will  likely 
become  much  more  prevalent  in  the  Finance  community.  New  sysiems 
development  must  be  undertaken  with  a  clear  idea  of  how  security  will  be 
afforded  to  dispersed  databases  in  the  client-server  environment.  The 
DOOMS  Network  Security  for  Information  Exchange  (DNSIX)  Interface 
Specifications  should  be  considered  to  provide  a  minimum  set  of  security 
services/protocols  required  for  compartmented  mode  networking. 
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Diskless  workstations  should  be  considered  for  the  primary  user 
workstation  as  a  means  of  providing  an  additional  level  of  security.  A 
diskless  workstation  has  no  removable  data  storage  media  and  may  not 
have  any  non  volatile  local  storage  installed.  The  diskless  configuration 
makes  the  information  system  much  less  susceptible  to  the  introduction 
of  viruses  that  can  alter,  destroy  or  deny  access  to  critical  data.  It  also 
makes  unauthorized  removal  of  data  from  the  system  much  harder  to 
accomplish  if  there  are  no  floppy  drives  installed. 

2.3.8.3  Applicable  Standards 

The  following  standards  and  guidelines  apply  to  security: 

0  DoD  5200.28-STD  -  DoD  Trusted  Computer  Systems 
Evaluation  Criteria 

0  POSIX  P1 003.6  -  POSIX  Security  Interface 
0  ISO  7498-2  -  OSI  Reference  Model 

0  DRS-2600-5502-87  Compartmented  Mode  Workstation(CMW) 

0  DDS-2600-6243-91 ,  Version  1  -  CMW  Evaluation  Criteria 

0  DDS-2600-6216-91  -  CMW  Labeling:  Encoding  Format 

0  DDS-2600-6215-91  -  CMW  Labeling:  Source  Code  and  User 
Interface  Guidelines 
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2.3.8.1  Digital  Signature 

2.3.8. 1.1  Current  Digital  Signature  Environment 

The  full  extent  of  use  of  digital  signatures  in  the  legacy  environment  is 
unknown  at  this  time.  Rudimentary  forms  of  digital  signatures  are  being 
used  by  some  systems  for  access  control  to  data.  Additional  information 
is  required  to  obtain  a  better  understanding  of  the  use  of  digital 
signatures  by  DFAS. 

2.3.8.1.2  Analysis  and  Guidance 

The  digital  signature  is  designed  to  provide  proof  of  a  document  sender's 
identity  and  that  the  contents  of  the  document  have  not  been  altered.  It 
can  be  of  great  use  in  the  Finance  community  for  authentication  of  funds 
transfer,  invoking  of  contracts  and  many  other  uses.  The  National 
Institute  of  Standards  and  the  National  Security  Agency  are  currently 
working  on  developing  a  digital  security  standard  that  can  be  used 
throughout  the  federal  government. 

The  digital  signature  is  comprised  of  a  signer's  public  and  private  key,  a 
hashing  algorithm,  and  public  and  secret  parameters  assigned  to  each 
message  sent  by  the  signer.  It  can  be  used  for  electronic  mail, 
negotiations,  software  protection,  data  protection  and  smart  cards.  As 
the  use  of  smart  cards  increases  for  identification  purposes  in  the 
Department  of  Defense,  the  use  of  secure  digital  signatures  becomes  very 
important.  New  system  design  should  investigate  the  use  of  digital 
signatures  where  feasible  to  protect  the  integrity  of  financial 
transactions. 

2.3.8.1.3  Applicable  Standards 
To  be  provided  in  next  version. 


Page  61 


2.3.9  System  Management 

2.3.9.1  Current  System  Management  Environment 

Detailed  information  on  network  management  and  configuration 
management  in  the  legacy  environment  has  not  been  collected  and 
analyzed.  Data  on  operating  systems  and  hardware  is  available  in  the 
Technical  Reference  Model  for  Information  Management,  the  DoD  Technical 
Architecture  Framework,  and  the  POSIX  Open  Systems  Environment  Guide. 
But  no  details  of  how  these  systems  are  managed  are  known  at  this  time. 
Most  likely  they  are  initiated  individually,  or  are  part  of  a  unique 
scheduling  process  that  may  or  may  not  be  useful  for  all  financial  area 
users. 

System  management  capabilities  are  the  tools,  technologies  and 
procedures  that  manage  the  technical  resources  used  to  deliver 
information  technology.  System  management  facilitates  the  use  of  and 
changes  to  technical  resources  that  deliver  Information  services. 
Configuration  management  is  a  function  of  systems  management 
responsibilities  for  controlling  and  coordinating  resources  falling  into 
categories  such  as  software,  communications,  data,  hardware  etc. 

Most  of  the  tools  and  technologies  that  compose  system  management 
capabilities  currently  in  use  are  application  software  products  also  known 
as  system  software  or  executive  software.  Traditionally,  these 
capabilities  were  provided  by  IBM  and  the  relatively  few  other  vendors 
providing  mainframe  processing  systems.  By  their  nature  (one  processor, 
one  location,  one  point  of  control,  one  vendor),  the  capabilities  are  simple 
to  manage.  In  contrast.  Finance  area  near-term  technical  architecture, 
including  client/server,  has  many  more  elements,  locations,  and  potential 
points  of  control.  As  the  consolidation  systems  evolve  toward  the  DoD 
objective,  the  delivery  of  information  services  will  continue  to  get  more 
and  more  complex.  As  the  systems  become  more  complex,  so  will 
managing  them.  System  management  capabilities  procured  from  various 
sources  will  have  to  be  integrated  over  the  entire  network. 
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When  appropriate  systems  management  capabilities  are  in  place,  the 
technical  resources  will  become  available  to  the  service  user  through  a 
"single  image."  That  is.  it  will  be  transparent  to  the  person  who  is  using 
the  service  that  he  or  she  is  working  with  several  different  computing 
resources.  They  will  appear  to  be  on  the  computer  he  or  she  is  working 
with.  Today  for  any  of  these  systems  to  work,  the  user  must  be  logged  on 
to  the  system  that  is  running  it.  Theoretically  a  finance  area  user  needing 
to  get  all  13  applications  would  need  13  different  logon  IDs. 

2.3.9.2  Analysis  and  Guidance 

All  migration  systems  are  running  under  MVS,  MS-DOS,  or  UNISYS.  All 
IPCs  should  be  under  change  control  for  all  OS  software  changes  and 
managed  from  a  single  point.  When  the  system  administrator  changes  the 
configuration,  all  applications  impacted  by  ^he  change  should  be 
identified.  Softv/are  releases  should  be  managed  by  defining  a  class  for 
them.  When  an  attribute  in  the  releases  iu  changed,  the  control  point 
should  initiate  a  process  to  distribute  the  software  to  all  recipients  so 
that  they  may  change  their  object  to  reflect  the  new  release. 

Each  new  release  of  the  application  software  must  be  under  formal 
control,  and  explicitly  identified  as  to  which  release  of  the  system 
software  it  can  work  under. 

All  restart  processes  either  must  be  standard  or  well  documented. 

Communications  use  and  products  are  unknown,  but  VTAM  and/or  SNA  must 
be  under  the  same  change  control  process  as  the  operating  system 
software. 
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As  the  legacy  systems  are  consolidated,  an  attempt  should  be  made  to 
adopt  distributed  architecture  as  a  means  of  integrating  existing 
heterogeneous  components.  For  instance,  the  application  end  users  should 
be  supported  by  workstations  connected  by  LAN.  Geographically  separated 
groups  might  be  connected  by  LAN  bridge.  The  application  running  on  the 
workstation  should  interact  with  source  of  data  running  on  mini  or 
mainframe  computers.  In  order  to  support  groups  of  people  involved  in  a 
common  activity,  workstation  based  applications  should  communicate 
with  each  other  over  this  network.  Action  taken  by  one  person  that  effect 
the  work  of  others  should  be  propagated  through  the  network  of 
application. 

The  consolidation  systems  will  have  one  user  interface  process  per  user. 
This  will  allow  the  system  configuration  to  allocate  a  unique  profile, 
which  will  customize  the  interface  based  on  the  user's  job.  Automatic  log 
in  and  log-out  may  be  implemented  by  associating  log-in  and  log-out 
script  files  with  each  user  interface,  thereby  making  the  process 
transparent  to  the  operator.  Security  will  be  implemented  through  the  use 
of  access  control  files.  These  files  will  be  designed  to  contain  the  names 
of  the  objects  that  are  to  be  protected,  the  names  of  the  users  who  may 
access  system  objects,  and  the  type  of  access  each  user  is  allowed.  The 
system  administrator  will  be  the  only  class  of  user  allowed  to  update 
these  files  to  establish  user  profiles  and  access  privileges.  An  audit  trail 
within  these  files  will  be  automatically  kept  on  the  access  attempts  and 
activities  of  each  user. 
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2.3.9.3  Applicable  Standards 

The  following  standards  and  guidelines  apply  to  system  management. 

0  System  Management  Component  -  NIST  Planned  FIPS  PUB  on 
Government  Network  Management  Profile  (GNMP)  and  Draft  Military 
Standard  2045-38000 

0  Government  Open  System  Interconnect  Profile  (GOSIP  Version 
2.0)  FIPS  PUB  146-1 

0  Kernel  Operations  Component  -  Portable  Operating  System 
Interface  for  Computer  Environments  (POSIX.1)  FIPS  PUB  151-1 

0  ISO  IS  7498-2,  Information  Processing  Systems  -  OSI\  Reference 
Model  -  Part  2 


2.3.9.1  Network  Management 

To  be  provided  in  a  future  version. 
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2.3.10  Workstations 

2.3.10.1  Current  Workstation  Environment 

The  current  workstation  environment  within  the  finance  community  is 
comprised  primarily  of  3270-type  terminals  with  a  small  number  of  non- 
3270  character-based  terminals  and  stand-alone  PCs. 

Workstations  for  the  current  legacy  and  migration  systems  are: 


Legacy  Systems  Migration  Systems 


NAVSCIPS 

3270 

DCPS 

3270  or  PC 

NAFCPS 

3270 

JUMPS-JSS 

3270 

DJMS 

3270  or  PC 

MCARS 

3270 

DRAS-NRPS 

3270 

DRAS 

3270  or  PC 

AFAPS 

3270 

DTPS-ATOS 

PC 

DTPS 

PC 

lATS 

PC 

TRIPS 

PC 

DTRS-TIPS 

Chdracter-based 

DTRS 

Character-based,  PC 

MOCAS 

3270 

MOCAS 

3270  or  PC 

AFDARS 

3270 

T 

DOMS 

3270  or  PC 

APCAPS 

3270 

DRMS 

3270 
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2.3.10.2  Analysis  and  Guidance 

The  DoD  long  range  objective  is  to  move  towards  easy-to-use,  flexible, 
and  scalable  end-user  computing  devices  (i.e.,  workstations).  The  goal  is  a 
single  multi-function  workstation  on  each  desktop  that  provides  all 
functional  capabilities  required  by  the  user.  The  workstation  will  be 
multi-tasking,  provide  the  required  platform  services  in  accordance  with 
the  standards  specified  in  this  Chapter,  and  have  sufficient  performance 
characteristics  to  support  one  of  the  client/server  processing  models 
specified  in  Volume  2  of  the  Technical  Architecture  Framework  for 
Information  Management. 

A  single  workstation  will  not  be  mandated  for  use  in  the  Finance 
community.  Instead  d  family  of  workstations  that  satisfy  the  technical 
requirements  will  be  available  to  system  developers.  The  workstation 
chosen  for  individual  use  will  depend  on  functional  requirements  and  the 
client/server  processing  environment.  The  possible  workstation  options 
include:  Personal  Comjauters  (PCs),  X-terminals,  and  high-performance 
workstations.  The  workstation  options  and  possible  uses  are  described 
below.  I 

PCs  -  The  PC  is  the  most  commonly  used  and  readily  available 
workstation.  Its  is  capable  of  supporting  the  services  required  by 
finance  end-user  jcomputing  devices.  Standard  PC  configurations 
will  be  the  most  common  workstation  solution  in  the  Finance 
community.  It  should  be  noted  that  PCs  can  be  configured  with  X 
Windows  software  that  enables  them  to  act  as  X-terminals. 

X-terminals  -  A  X-terminal  is  essentially  a  smart  terminal  that 
only  handles  presentation  management.  It  lacks  such  features  as 
high  speed  disk  controllers,  large  caches,  and  memory  management 
units.  X-terminal  hardware  and  software  are  optimized  for  running 
the  X-protocol  and  therefore  focus  on  network  communications, 
graphics  performance  and  graphical  user  interface  enhancements. 


Page  67 


I 


High-performance  workstations  -  High-performance  workstations 
provide  users  with  increased  desktop  computing  capabilities.  For 
stand-alone  applications  that  require  high-horsepower  computing, 
these  workstations  must  be  used.  Possible  applications  include 
simulation,  modeling,  and  computer-aided  software  engineering. 

Each  of  these  workstation  options  can  be  implemented  in  configurations 
with  and  without  disks  (both  fixed  and  removable).  Diskless  workstations 
can  be  used  when  accessing  distributed  databases,  using  corporate  data, 
primary  application  is  entry  and  validation  of  data,  primary  application  is 
office  automation,  user  access  and  virus  protection  are  of  paramount 
concern.  Diskless  workstations  should  not  be  used  when  autonomy  is 
paramount  or  when  communications  support  is  limited  or  unreliable. 

During  the  consolidation  phase  3270  and  character  based  terminals  should 
not  be  procured.  In  environments  where  3270  terminals  are 
needed  to  interoperate  with  legacy  systems,  one  of  the  three  workstation 
configurations  mentioned  above  should  be  used  (with  the  addition  of  3270 
emulation  softv/are).  When  replacing  3270  terminals  and  existing 
workstations  that  do  not  meet  the  long  range  objectives,  one  of  the  three 
configurations  should  be  used. 

Figure  2-10  provides  the  migration  path  for  workstations. 

2.3.10.3  Applicable  Standards 
The  following  standards  apply  to  workstations: 
oTBD 
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New  3270-Type 
and 

Character-Based 

Workstations 


Objective 


Standard 

Services 

^32  bit  Multifunction 


Consolidation  Systems  Environment 
Existing  j  | 


3270-Type 
and  I 
Character-  | 
Based 

Workstations  • 


j  232  bit  Multifunction  * 

I  I  PCs 


Existing  3270-Type 
and  Character-Based 


Legacy  S;^  <’ms  Environment 
•  • 

I  I 

I  1 232  bit  MuifWuncfion|  *=3 

I  I 


<32  bit  CISC  PCs 


FIGURE  2-10:  V/ORKSTATION  MIGRATION  PATH 


2.4  Communications 

This  section  defines  the  communications  layer  of  the  Finance  Technical 
Architecture.  The  communications  layer  provides  services  that  enable 
information  exchange  between  end-devices  distributed  world-wide  and 
supports  the  exchange  of  different  types  of  information  including:  data, 
voice,  and  imagery.  End  devices  include  platforms,  video  teleconferencing 
devices,  telephones,  facsimile  machines,  and  sensing  devices.  The 
communications  layer  services  combined  with  the  network  services 
provided  by  the  platform  layer  form  that  part  of  the  system  which 
transfers  information.  This  section  will  discuss  the  hardware  and 
software  required  to  provide  communications  services  to  the  Defense 
Finance  and  Accounting  System  (DFAS)  in  the  near-term  and  Include  a 
brief  characterization  of  the  existing  baseline  capability  if  one  exists. 
Migration  analysis  and  guidance  is  provided  to  support  both  the  near  term 
finance  and  accounting  consolidation  efforts  as  well  as  long  range  DoD 
objectives  to  establish  an  open  distributed  computing  environment. 

2.4.1  Current  Communications  Environment 

The  current  Communications  legacy  environment  is  primarily  an  IBM 
Systems  Network  Architecture  (SNA)  consisting  of  mostly  3270  terminals 
or  PCs  emulating  3270  terminals.  The  Wide  Area  Network  (WAN)  consists 
of  three  levels:  the  Defense  Data  Network  (DDN),  IDNX  Smart  Mux,  and  a 
router  based  TCP/IP  network.  The  overall  communications  infrastructure 
currently  consists  of  one  primary  transport  level,  therefore  the  - 
communications  structure  is  labeled  "Flat." 

Additional  information  is  required  in  order  to  obtain  a  better 
understanding  of  the  financial  legacy  Communications  environment. 
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Communications  for  the  current  legacy  and  migration  systems  are  as 
follows: 


Legacy  Systems  Migration  Systems 


NAVSCIPS 

SNA  Protocols 

DCPS 

SNA  Protocols 

NAFCPS 

SNA  Protocols 

JUMPS-JSS 

SNA  Protocols 

DJMS 

SNA  Protocols 

MCARS 

SNA  Protocols 

DRAS-NRPS 

SNA  Protocols 

DRAS 

SNA  Protocols 

AFAPS 

SNA  Protocols 

DTPS-ATOS 

TBD 

DTPS 

TBD 

lATS 

TBD 

TRIPS 

TBD 

DTRS-TIPS 

UNISYS  Protocols 

DTRS 

TBD 

MOCAS 

SNA  Protocols 

MOCAS 

SNA  Protocols 

AFDARS 

SNA  Protocols 

DDMS 

SNA  Protocols 

APCAPS 

TBD 

DRMS 

TBD 

2.4.2  Analysis  and  Guidance  ^ 

1 

The  DoD  objectiye  enyironment  for  Communications  is  to  moye  toward  an 
open  systems  architecture  that  conforms  to  GOSIP,.  Additionally,  the  DoD 
has  defined  the  communications  infrastructure  to  consist  of  three 
transport  leyels:  Local,  Regional,  and  Global.  Analysis  and  guidance  for 
the  three  transport  leyels  are  presented  below.  1 
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2.4.2. 1  Local 


The  "Local"  architecturD  should  include  fundamental  standards  or 
guidelines  for  the  following: 

0  Physical  Wiring 

0  Premises  Distribution 

a  Local  Area  Networks 

A  common  configuration  is  recommended  for  both  voice  and  data  for 
premises  distribution  systems.  Common  cabling  plants  should  be 
considered  for  data,  voice,  and  video  services  to  each  end-user  location. 
Given  the  large  percentage  of  existing  3270-type  terminals,  it  may  not  be 
cost  effective  to  rewire  at  the  premises  distribution  level.  If 
LAN-attached  PC  devices  replace  the  3270-type  terminals,  then 
recommendations  and  guidelines  should  be  established  for  all  new 
implementations. 

LANs  should  be  used  to  provide  access  to  all  desired  network  services. 
Adherence  to  corporate  security  guidelines  and  naming  standards  is 
required.  LAN  components  should  provide  management  capability  such  as 
Simple  Network  Management  Protocol  (SNMP).  Operating  systems  should 
be  standards  based  and  servers  should  be  scalable.  Access  to  other 
communications  networks  should  be  provided  using  communication 
gateways.  Bridges  should  be  used  to  interconnect  LAN  segments  that  are 
located  within  the  same  work  group  or  building. 
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2.4.2.2  Regional 

The  "Regional"  architecture  should  Include  fundamental  standards  or 
guidelines  for  the  following: 

0  Campus  Area  Network  (CAN) 

0  Metropolitan  Area  Network  (MAN) 

0  Wide  Area  Network  (WAN) 

CAN  and  MAN  operating  systems  should  be  standards-based.  Servers 
should  be  scalable.  Routers  should  be  used  to  interconnect  LANs  and  CANs 
by  the  services  provided  by  a  WAN.  Bridges  and  repeaters  can  be  used 
within  a  local  work  group  or  site.  The  router's  protocol  should  be  based  on 
open  standards  to  ensure  that  all  routers  will  interoperate. 

TCP/IP  should  be  used  at  the  transport  and  network  layer  protocol  suite. 
Open  Shortest  Path  First  (OSPF)  protocol  should  be  used  by  the  TCP/IP 
routers.  Intermediate  System-Intermediate  System  (IS-IS),  End 
System-Intermediate  System  (ES-IS)  and  End  System-End  System  (ES-ES) 
routing  protocols  should  be  used  on  OSI-based  networks. 

Multi-protocol  routers  should  be  considered  for  specific  traffic 
requirements.  Bridges  and  repeaters  should  not  be  used  for  LAN 
interconnection  over  a  Wide  Area  Network  (WAN). 

Analysis  and  guidance  for  WAN  components  of  the  Regional  transport  level 
are  covered  in  the  "Global"  section  below. 

2.4.2.3  Global 

WANs  should  use  end-to-end  digital  transmission  facilities  based  on  open 
International  standards  and  incorporating  the  appropriate  combination  of 
public  and  private  facilities. 


Page  73 


The  DoD  has  mandated  that  OSI  specifications,  as  defined  by  GOSIP,  be 
supported  on  all  Government  contracts.  TCP/IP  provides  limited 
capability  compared  to  OSI,  but  is  a  stable  protocol  that  is  widely 
supported  by  vendors  and  is  generally  interoperable  between  different 
vendors.  Interfaces,  translation  packages,  and  emulation  packages  are 
frequently  used  to  circumvent  incompatibility  problems.  Proprietary 
protocols  are  unlikely  to  disappear  even  with  the  emergence  of  OSI 
because  proprietary  protocols,  built  to  support  the  specific 
characteristics  of  a  vendor's  components,  are  often  much  faster  and  more 
manageable  within  that  vendor's  components  than  generic,  standard 
protocols. 

Proprietary  networks  should  not  be  used  to  transport  open  protocols  (i.e., 
TCP/IP  should  not  be  transmitted  over  an  SNA  network).  TCP/IP  gateways 
should  be  used  to  interconnect  disparate  LANs.  Figure  2-11  provides  the 
migration  path  for  communications. 


Proprietary  Protocols 
Character  Mode  Data 
Transfer  Analog  Circuits 


GOSIP 


'FLAT  Stnjcture 


FIGURE  2-11:  COMMUNICATIONS  MIGRATION  PATH 


/ 


2.4.2.4  Analysis  and  Guidance  Summary 

Communications  components  for  current  environment  and  recommended 
environment  are  as  follows: 


3270  Coaxial  Cable  Runs, 
Coaxial-wired  LANs 


Unshielded  Twisted  Pair  (UTP), 
Shielded  Twisted  Pair  (STP) 
for  noisy  environments, 
or  Fiber  Optic  (FO) 


3270  terminal  or  PC  with 
emulation  adapter 


LAN-attached  PC  and  3270 
gateway  I 


Proprietary  Network 
Operating  System 


Non-Proprietary  Network 
Operating  System 


Non-iEEE802  Series  LAN 


Non-GOSIP  compliant  LANs 


IEEE802  Series  LAN 


GOSIP  compliant  LANs 


WAN  UN  bridges 
Proprietary  protocols 


WAN  UN  nbuters 


Standards  based  protocols 


Proprietary  network  transporting 
Open  Systems  protocols 


Open  Systems  transportif 
Proprietary  &  OSI  netwc'-’ 
protocols 


Analog  circuits 

Flat  communications  structure 
Varied  network  management 

2.4.3  Applicable  Standards 


Digital  circuits 

Local/Regional/Global  structure 
Standards-based  network 
management 
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2.4.3.1  Local 


0  Government  Open  Systems  Interconnection  Profile  (GOSIP) 
0  NIST  Specification  Pub  500-163 

0  ISO  8802/3,  IEEE  802.3  Ethernet 

0  ISO  8802/4,  IEEE  80  Token  Bus 

0  ISO  8802/5,  IEEE  802.5  Token-Ring 

0  ANSI  X3T9.5  Fiber  Distributed  Data  Interface  (FDDI) 

0  ANSI  FDDI  11 

0  Copper  Distributed  Data  Interface  (CDDI)  [future] 

0  Defense  Data  Network  (DDN)  RFC-xxx 
0  Transmission  Control  Protocol  /  Internet  Protocol  TCP/IP) 
2.4.3.2  Regional 

0  ISO  8802/3,  IEEE  802.3  Ethernet 
0  ISO  8802/5,  IEEE  802.5  (16Mbps  only)  Token- '-’iig 
0  lEtE  802.6  Distributed  Queue  Dual  Bus  (DQDB)  [future] 

0  ANSI  X3T9.5  FDDI 
0  ANSI  FDDI  II 
0  CDDI  [future] 


Page  77 


0  open  Shortest  Path  Firt>t  (OSPF) 

0  OSI  Intermediate  System-Intermediate  System  (IS-ISy 
0  OSI  End  System-Intermediate  System  (ES-IS) 

0  OSI  End  System-End  System  (ES-ES) 

0  OSI  Integrated  IS-IS  (future] 

Applicable  Standards  for  Wide  Area  Network  (WAN)  components  of  the 
Regional  environment  are  covered  in  the  section  "Global"  below. 

2.4.3.3  Global 

oGOSIP 

0  T1,  T3,  DS-3,  Fractional  T1 
0  Switched  Digital  Data  Service  (SW/DDS) 

0  Asynchronous  Transfer  Mode  (ATM) 

0  Integrated  Services  Digital  Network  (ISDN)/ 

0  Basic  Rate  Interface  (BRI) 

0  Primary  Rate  Interface  (PRI) 

0  Broadband  Integrated  Services  Digital  Network  (BISDN) 

0  CCITT  X.25  Interface  between  DTE  and  DCE  for  Terminals 
0  Operating  in  Packet  Mode  and  Connected  to  Public 
0  Domain  Networks  by  Dedicated  Circuits. 
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o  Synchronous  Optical  Network  (SONET) 
0  ANSI  T1.606  Frame  Relay 


